…tency

RdfIndexApp ran daily and never reconciled removed relationships, so triples
grew unboundedly across runs. When Fuseki crash-looped on the resulting disk
pressure, every entity-write hook blocked synchronously on the unreachable
server (no HTTP connect timeout, 3-retry loop on ConnectException), saturating
the bounded AsyncService pool and pushing login to ~45s.

Storage-side fixes (stop growth):
- Drop the extractRelationshipTriples "preserve forward" path in
  RdfRepository.createOrUpdate; the translator is the source of truth and the
  surrounding orchestration already rewrites the current relationship set.
  This also removes a wasted CONSTRUCT round-trip per entity write.
- bulkStoreRelationships now does per-source-entity DELETE WHERE with a
  predicate-exclusion FILTER for lineage edges, so relationships that no
  longer exist actually leave the store.
- Wire RdfRepository.clearAllGlossaryTermRelations() into RdfIndexApp's
  initializeJob (the method existed but had no callers).
- Flip recreateIndex default to true and move the cron to Saturday midnight
  ("0 0 * * 6"). Add reloadOntologies() so CLEAR ALL doesn't leave the
  ontology graph empty before indexing starts.
- Include a 2.0.1 post-data migration that updates existing installed_apps
  rows; the app loader is insert-only on upgrade.

Connectivity / concurrency fixes (isolate API latency from Fuseki health):
- Add 2s connectTimeout to every JenaFusekiStorage HttpClient and fast-fail
  on ConnectException / ClosedChannelException / HttpConnectTimeoutException
  instead of retrying. Introduce a 5-failure/30s circuit breaker.
- Route all RdfUpdater mutators through AsyncService.execute with a bounded
  pendingWrites gate (cap 1000, drop-on-overflow with logged warning) so a
  dead Fuseki can no longer block request threads or starve the AsyncService
  pool.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…surface ontology failures

PR #28117 review feedback. Addresses 13 findings across gitar-bot and Copilot:

Storage correctness:
- JenaFusekiStorage.storeEntity now keeps URI-valued triples (relationships)
  and only refreshes literal-valued triples. A metadata-only PATCH would
  otherwise wipe every inter-entity edge until the next weekly recreate-index,
  and async ordering between updateEntity and addRelationship could leave the
  graph missing edges (Copilot #1, #2).
- RdfRepository.removeRelationship wraps the DELETE in the knowledge named
  graph and uses getRelationshipPredicate so the predicate URI matches what
  addRelationship actually wrote (e.g. UPSTREAM → prov:wasDerivedFrom). The
  previous bare DELETE in the default graph was a silent no-op (Copilot #3).
- RdfBatchProcessor now calls a new RdfRepository.clearOutgoingEntityRelationships
  for every entity in the batch, not just those with current edges. An entity
  whose last outgoing relationship was removed in MySQL contributes zero
  RelationshipData entries, so bulkStoreRelationships' per-source DELETE
  never fired for it (Copilot #4).
- bulkStoreRelationships no longer swallows non-connect DELETE errors —
  DELETE WHERE on a source with no edges is a no-op, so exceptions there
  are real failures (malformed SPARQL, auth, server errors) and should
  surface (Copilot #5).

Visibility:
- reloadOntologies() now checks areOntologiesLoaded() after load and throws
  if still empty. OntologyLoader.loadOntologies catches internally, so the
  old reloadOntologies always appeared to succeed (Copilot #6).
- clearAllGlossaryTermRelations rethrows on failure instead of silently
  logging — the indexer's caller can now react to cleanup failures (Copilot #10).
- clearAllGlossaryTermRelations pulls custom predicate URIs from
  GlossaryTermRelationSettings and includes them in the DELETE FILTER. The
  hardcoded list missed any custom predicates an admin configured (Copilot #7).

Quality:
- Set / LinkedHashSet imported instead of using java.util.* fully qualified
  in JenaFusekiStorage and RdfBatchProcessor (gitar-bot #2).
- RdfIndexAppTest uses InOrder to assert clearAll → reloadOntologies
  ordering — a plain verify would have accepted a future change that
  reordered the calls (Copilot #9).
- Documented the residual gap that HttpClient.connectTimeout only bounds
  TCP connect, not request bodies; circuit breaker + bounded pendingWrites
  contain the blast radius (Copilot #8).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… all filtered

The two EventSubscription-skip tests used verifyNoInteractions on the RDF
repository mock, which was valid before because filtered batches never
touched RDF. The new per-source reconciliation clear in
RdfBatchProcessor.processBatchRelationships now runs for every batch entity
regardless of whether its relationships survive filtering — that's
deliberate, since stale RDF state for those source entities still needs
to be reconciled even when their current MySQL edges all point to excluded
entity types. Switch the assertions to verify clearOutgoingEntityRelationships
is the sole interaction (no bulkAdd, no addRelationship).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…se it

JenaFusekiStorage (org.openmetadata.service.rdf.storage) lives in a different
package than RdfRepository (org.openmetadata.service.rdf), so the
package-private buildPredicateInList helper introduced in 857c09 couldn't be
called from JenaFusekiStorage.bulkStoreRelationships — CI was failing with:

  [ERROR] JenaFusekiStorage.java:[606,51] buildPredicateInList(Set<String>)
  is not public in RdfRepository; cannot be accessed from outside package

Promote it to public alongside RELATIONSHIP_HOOK_PREDICATES (which is the
only data this helper renders) so the cross-package call resolves. Local
javac across the touched RDF files now reports zero new errors; the only
remaining build failures are the pre-existing es.co.elastic.clients shading
issues unrelated to this PR.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…lationships 2-arg signature

Three test failures after the Fix-I / atomic-clear-insert changes:

- testProcessBatchRelationshipsStoresResults verified
  `bulkAddRelationships(captor.capture())` (1-arg) but RdfBatchProcessor now
  calls the 2-arg `bulkAddRelationships(relationships, batchSources)` — Mockito
  surfaced this as "different arguments" because the actual call had a
  Set<EntitySourceRef> tail. Updated the verify to
  `bulkAddRelationships(captor.capture(), anySet())`.

- The two event-subscription skip tests previously verified
  `clearOutgoingEntityRelationships(anySet())` as the only interaction; that
  method is no longer called from RdfBatchProcessor (the clear was folded
  into bulkAddRelationships' atomic SPARQL transaction for safety). Replace
  with `verify(mockRdfRepository).bulkAddRelationships(eq(List.of()), anySet())`
  — bulkAdd is still invoked with an empty list to drive the per-source
  reconciliation for the batch entity, even when the only fetched
  relationship pointed at an excluded entity type.

Filtered local compile + test-compile passes cleanly (no NEW errors from RDF
files; only pre-existing es.co.elastic.clients shading errors remain).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

- collectTranslatorPredicates over-broad (3249798300): RdfRepository.addRelationship
  passes storeEntity a model loaded from Fuseki PLUS the new relationship, so the
  dynamic walk was pulling hook-managed predicates (om:owns, etc.) into the DELETE
  scope. With async writes, two concurrent additions for the same source could
  each read the old model and each storeEntity wipe the other's relationship.
  Exclude RELATIONSHIP_HOOK_PREDICATES from the walk result (and defensively from
  the static-set union too).

- ForkJoinPool.commonPool starvation (3249798327): runWithTimeout used
  CompletableFuture.supplyAsync's default executor, so a Fuseki that stalls would
  leak workers on the JVM-wide commonPool and starve unrelated CompletableFuture
  / parallel-stream work. Introduce a dedicated virtual-thread executor
  (Thread.ofVirtual().name("rdf-storage-timeout-", 0)) and route all timeout
  wrappers through it — virtual threads are cheap to leak and the circuit breaker
  bounds the pile-up.

- Shrink-to-empty for literal predicates (3249798383): the predicate-scoped DELETE
  no longer caught stale literals when a literal-valued field (description /
  displayName / …) was cleared and the new model simply omitted the triple. Chain
  a "DELETE … FILTER(!isIRI(?o))" pass with the URI-scoped pass so hook-managed
  URI triples stay intact while stale literals get swept on every write.

- UI schema default (3249798439): the UI form schema at
  utils/ApplicationSchemas/RdfIndexApp.json still declared recreateIndex.default
  = false. Flipped to true to match the backend openmetadata-spec schema and the
  install JSON files. (The sibling jsons/applicationSchemas/ is gitignored
  generated output, no source change needed there.)

Local verification before push: spotless:apply, filtered compile + test-compile
(zero new errors), and `mvn test -Dtest='RdfIndexAppTest,RdfPropertyMapperTest,
RdfPredicatePartitionTest,RdfStorageIdempotencyTest'` — 64 tests, 0 failures.

The "buildPredicateInList package-private" finding from the same review
(3249798351) is already addressed in 03c5d4f and surfaces here only because
Copilot reviewed an earlier commit.

The "lineage incremental cleanup" finding (3249798415) is a known architectural
trade-off: addLineageWithDetails handles current lineage rows but removed edges
have no row to trigger a per-edge delete, and adding UPSTREAM/wasDerivedFrom to
RELATIONSHIP_HOOK_PREDICATES would conflict with the inline addLineageWithDetails
call that runs BEFORE bulkAddRelationships in RdfBatchProcessor. The weekly
recreateIndex=true run (the new default) wipes and rebuilds from MySQL, which
reconciles stale lineage; left this thread open as a documented gap rather
than reordering processBatchRelationships in this PR.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>